Innovations in data communications technology, fueled by bandwidth-intensive applications, have led to a ten-fold improvement in networking hardware throughput occurring about every four years. These network performance improvements, which have increased from 10 Megabits per second (Mbps) to 100 Mbps, and now to 1-Gigabit per second (Gbps) with 10-Gigabit on the horizon, have outpaced the capability of central processing units (CPUs). To compensate for this dilemma and to free up CPU resources to handle general computing tasks, offloading Transmission Control Protocol/Internet Protocol (TCP/IP) functionality to dedicated network processing hardware is a fundamental improvement. TCP/IP chimney offload maximizes utilization of host CPU resources for application workloads, for example, on Gigabit and multi-Gigabit networks.
TCP/IP chimney offload provides a holistic technique for segmenting TCP/IP processing into tasks that may be handled by dedicated network processing controller hardware and an operating system (OS). TCP/IP chimney offload redirects most of the TCP/IP related tasks to a network controller for processing, which frees up networking-related CPU resources overhead. This boosts overall system performance, and eliminates and/or reduces system bottlenecks. Additionally, TCP/IP chimney offload technology may play a key role in the scalability of servers, thereby enabling next-generation servers to meet the performance criteria of today's high-speed networks such as Gigabit Ethernet (GbE) networks.
Although TCP/IP offload is not a new technology, conventional TCP/IP offload applications have been platform specific and were not seamlessly integrated with the operating system's networking stack. As a result, these conventional offload applications were standalone applications, which were platform dependent and thus severely affected deployment. Furthermore, the lack of integration within an operating system's stack resulted in two or more independent and different TCP/IP implementations running on a single server, which made such systems more complex to manage.
TCP/IP chimney offload may be implemented using a PC-based or server-based platform, an associated operating system (OS) and a TCP offload engine (TOE) network interface card (NIC). The TCP stack is embedded in the operating system of a host system. The combination of hardware offload for performance and host stack for controlling connections, results in the best OS performance while maintaining the flexibility and manageability of a standardized OS TCP stack. TCP/IP chimney offload significantly boosts application performance due to reduced CPU utilization. Since TCP/IP chimney offload architecture segments TCP/IP processing tasks between TOE's and an operating system's networking stack, all network traffic may be accelerated through a single TCP/IP chimney offload compliant adapter, which may be managed using existing standardized methodologies. Traditional TCP offload as well as TCP chimney offload are utilized for wired and wireless communication applications.
Internet Small Computer System Interface (iSCSI) is a TCP/IP-based protocol that is utilized for establishing and managing connections between IP-based storage devices, hosts and clients. The iSCSI protocol describes a transport protocol for SCSI, which operates on top of TCP and provides a mechanism for encapsulating SCSI commands in an IP infrastructure. The iSCSI protocol is utilized for data storage systems utilizing TCP/IP infrastructure.
There may be a plurality of challenges with providing a complete and robust iSCSI boot implementation. The boot process goes through from real mode to protected mode, from BIOS governed to OS controlled environment, through various phases of the OS boot, where memory ownership and control may change frequently. Multiple physical devices may try and control the memory or may need software to be present in memory for proper operation. As this environment is not subject to standardization, the memory content may be altered, where multiple devices may compete for the same space. The memory space available in real mode is very limited.
The iSCSI boot solution needs to be complete. As it enables a machine to use a remote network resident storage device as if it was a locally attached hard drive, it must also provide the service for a crash dump scenario. In this scenario, the OS crashes and a dump of the memory along with potentially other state information is stored on the hard disk. This needs to be supported over the iSCSI connection, which is challenging, as the OS is not in its full running mode and driver model and memory model are different.
Further limitations and disadvantages of conventional and traditional approaches will become apparent to one of skill in the art, through comparison of such systems with some aspects of the present invention as set forth in the remainder of the present application with reference to the drawings.